Centralized payment hub method and system

ABSTRACT

Embodiments described herein include an electronic transaction service network (also referred to herein as a centralized electronic transaction (CET) service). In another embodiment, a financial management system hosts a “central payment hub” version of the CET service. The central payment hub is an industrial utility in that multiple financial institutions all participate in a central service that can be offered to their respective customers. All of the customers (both individuals and small businesses) of the various institutions come to one consolidated payment hub. For example a Bank of America invoice can come into the payment hub, and a Wells Fargo invoice can come into the payment hub. The payment hub is a shared utility across multiple financial institutions. The payment hub features a single registration at the payment hub across all of the participating financial institutions.

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication Ser. No. 60/926,619, filed Apr. 27, 2007. This applicationalso claims the benefit of U.S. Provisional Patent Application Ser. No.60/957,634, filed Aug. 23, 2007.

This application is related to U.S. patent application Ser. No.11/879,818, filed Jul. 19, 2007.

TECHNICAL FIELD

The invention is in the field of electronic payment methods and systems,including electronic financial networks.

BACKGROUND

Currently there are systems and methods for facilitating onlinetransactions. FIGS. 1 and 2 illustrate one current system 100 used tofacilitate making payments for online purchases. There are twocategories of payment services available in such traditional systems.One category includes person-to-person and person-to-merchant paymentservices. The other category includes direct-to-merchant paymentservices. In such traditional methods, a user must open an account 104with the service, referred to in FIGS. 1 and 2 as “X” service, and theuser must fund the account. The account 104 must be funded using anexternal financial source 102, such as a checking account, a creditcard, etc. In addition, funds must be kept on deposit in the account 104for transfer or disbursement. The funds are transferred to the account104 by the user with no sharing of information, such as informationregarding other user accounts, or user creditors, etc. Money in theaccount 104 can be used for any of account service 112 offered by “X”service. Funds from the account 104 are distributed to payees 106 whenthe user performs a transaction that allows use of the “X” service,including payments to individuals 106A and to online stores 106B.Payment services 108 for person-to-person payments, and payment services110 for direct-to-merchant payments are shown. Examples of suchtraditional services include the PayPal™ service.

However, current systems and methods for facilitating onlinetransactions have significant limitations. FIG. 2 illustrates variouslimitations of the “X” service. For example, settlement time 113 forpayment from the external financial source 102 to the user account 104can be 3 to 4 days using a DDA account. When funds are transferred fromthe account 104 to multiple destination accounts 105, an additional 3 to4 days settlement time is incurred in transferring the funds from thedestination accounts 105 to a main bank account 117. This creates aworst-case settlement time of up to 8 days, not including any delayscaused by verification processes at any transfer point.

Another disadvantage of such current systems is that the user must fundand manage the account 104 with “X” service as a separate account andrelationship distinct from any other payor or payee relationships.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1 and 2 illustrate a prior art system used to facilitate makingpayments for online purchases.

FIG. 3 is a block diagram illustrating an embodiment of a centralizedelectronic transaction (CET) service, which provides improved settlementtime over existing payment methods, according to an embodiment.

FIG. 4 is a block diagram further illustrating direct-to-merchantpayment CET services and person-to-person payment CET services,according to an embodiment.

FIG. 5 is a block diagram illustrating biller-direct invoicing foroffline merchants, according to an embodiment.

FIG. 6 is a block diagram illustrating an embodiment in which the CETservice and network is used by the “unbanked” to conduct transactions,according to an embodiment.

FIG. 7 is a block diagram of a system including a financial managementsystem providing a CET system, according to an embodiment.

FIG. 8 is a block diagram illustration the operation of a funds transfermodule, according to an embodiment.

FIG. 9 is a flow chart illustrating a CET service process, according toan embodiment.

FIG. 10 is a flow chart illustrating a CET service process ofregistering a user, according to an embodiment.

FIG. 11 is a block diagram of a system including a financial managementsystem that hosts a central payment hub, according to an embodiment.

DETAILED DESCRIPTION

Embodiments described herein include an electronic transaction servicenetwork (also referred to herein as a centralized electronic transaction(CET) service). According to an embodiment, a financial managementsystem hosts multiple CET web sites on behalf of multiple merchants. Alltransactions through any CET web site are executed and managed by thefinancial management system. Merchants may customize their web sites toinclude a branded look and feel. The merchant web sites are part of aCET service for which customer can register. Registered customers canthen view and pay invoices from any merchants having CET web sites,whether purchases were made online or offline. Customers specifypreferences for the CET service including choosing existing customeraccounts from which the financial management system is to pay invoiceson behalf of the customer. This eliminates the need for the customer toopen and fund a separate payment account as in traditional methods.

The financial management system handles all transactions and datastorage on behalf of merchants. Embodiments leverage existing financialinstitution (FI) payor and merchant networks. This allows merchants whoare not large enough to provide online payment through conventionalsystems to have convenient online invoicing and payment services tooffer their customers. This also allows customers of the financialmanagement system to easily pay many different merchants online using acustomer's existing account (such as a checking account, savingsaccount, or credit card). Embodiments do not require a user to create,fund and maintain a separate account for the purpose of paymentservices. In an embodiment, a user or customer registers with thetransaction CET service. The user is not required to create, fund andmaintain a separate account in order to user the CET service. The term“user” and “customer” will be used interchangeably herein.

According to various embodiments, individuals who are “unbanked” (e.g.,individuals who have no access to checking accounts, credit cards orother convenient non-cash payment mechanisms) may register with the CETservice, and transact with online and offline merchants and make onlinepayments.

One possible implementation of the CET service is by a small businessthat is part of the CET service. The business can create an invoice andsend the invoice out to the customer, by mail or electronically. Thecustomer, who is registered with the CET service, can access the invoiceelectronically, and automatically pay that invoice, for example throughthe customer's bank account.

Accounts payable can also be managed using the CET service. For example,consider a business that maintains a running account with a particularvendor. The business does not receive an invoice from the vendor, butcan login to the CET service, view the account balance, andelectronically pay the balance from another financial account of thebusiness. The financial information does not need to be shared betweenthe two entities.

Another functionality according to an embodiment is payroll management.For example, the business can login to the CET service and view payrollinformation. For employees who are also registered with the CET service,the business can pay the employee electronically from the business'sfinancial account at a financial institution to the employee's chosenaccount at a (probably, but not necessarily, different) financialinstitution.

One embodiment of the CET service includes a branded biller-direct site.In contrast to previous methods, in which a customer or user logs intoan “X” service web site, a biller-direct web site exists for themerchant or business. The business has the ability to customize the lookand feel of this web site, which may be branded by the merchant orco-branded with the CET service. In an embodiment, there is a directlink to the (branded or co-branded) CET service web site from thebusiness web site. An invoice, an email or some other communication issent from the business to the customer with an indication that therequired payment can be made directly on the business's CET service website (the link to the web site is provided). The link takes the customerto the branded web site. In an embodiment, the web site includes theicon of the business and a CET service icon.

Co-branding embodiments include cross-sell opportunities. For examplethe consumer logging on to view a merchant invoice can be provided withinformation regarding promotions and discounts of the merchant. Inaddition, a business logging on to view its account information can beprovided with information regarding network services.

In various embodiments, the CET service can be accessed in a variety ofways. For example, the user can login to the CET service web site andview the account information available for the user. The accountinformation available for the user includes information related to allof the businesses with which the user has accounts that are alsoregistered with the CET service. When the user clicks on an invoice of aparticular business, a detail window with the invoice information alsodisplays the branding of the invoicing business, as well as anycross-sell messaging provided by the invoicing business. Alternatively,the user can login to a business web site and view the user's accountinformation for that particular business (e.g., via a link as previouslydescribed).

Businesses participating in the CET service may access variousinformation when logged into the CET service web site. For example, allaccounts receivable information for those customers participating in theCET service is visible. In addition, accounts payable information isalso visible for those vendors participating in the CET service. Thus, aconsolidated view of accounts, both receivable and payable, is availableto the business participant. In addition, businesses can also leveragethe service to make point of sales payments associated with an onlineshopping cart.

Non-business users can perform various functions when logged into theCET service. For example, the user can view the invoices placed there bya business, the user can pay invoices directly using the CET service,and the user can view a consolidated statement that includes paymenthistory. Users can also leverage the service to make point of salepayments associated with a merchant shopping cart.

According to an embodiment, even if invoices are received offline, auser may still use the CET service web site to pay directly because themerchant or business knows the user and is aware of the relationship andaccount status. The web site can be used to remit the payment directlyto the merchant account.

An existing user bank account is used to fund transactions according tothe CET service. This is in contrast to having to create, fund andmaintain a separate “X” service account as in existing payment methodsand systems.

According to embodiments, the CET service offers rewards and otherloyalty programs to users for participation in the CET service (e.g.,for registering and completing transactions using the CET service). Therewards can be redeemed for goods, services, discounts, etc. This is incontrast to existing payment methods and systems, which do not makerewards available.

One embodiment of the CET service is implemented by a single financialinstitution offering the service to their customer. For example, thefinancial institution offered customers to sign up for the CET service(which may be branded by the financial institution or co-branded withthe financial management system hosting the CET service) on thefinancial institution web site. In such embodiments, the financialinstitution also offers business customers the opportunity to havebiller-direct web sites as described above, rather than the financialinstitution offering businesses this capability. In this scenario, thefinancial institution is in charge of the relationship with theparticipating merchants.

In another embodiment, the financial management system hosts a “centralpayment hub” version of the CET service. The central payment hub is anindustrial utility in that multiple financial institutions allparticipate in a central service that can be offered to their respectivecustomers. All of the customers (both individuals and small businesses)of the various institutions come to one consolidated payment hub. Forexample a Bank of America invoice can come into the payment hub, and aWells Fargo invoice can come into the payment hub. The payment hub is ashared utility across multiple financial institutions. The payment hubfeatures a single registration at the payment hub across all of theparticipating financial institutions. In an embodiment, the payment hubappears to users (individuals and small businesses) as a single,neutrally branded payment center across all of the participatingfinancial institutions. Therefore, there is a single registrationrequired in order for users to participate through any participatingfinancial institution's web site or participating small business's website.

FIG. 3 is a block diagram illustrating an embodiment of a CET service300, including improved settlement time over existing payment methods,according to an embodiment. There is a single relationship model withthe CET service; a user does not have to maintain a relationship andfinancial account with a separate payment service entity. Instead, theuser selects among multiple funding options 302 including existing userbank accounts and credit cards. This provides several advantages.Because the primary account 302 designated by the user acts as thetransactional account for the ET service, expanded capabilities of theprimary account 302 are seamlessly available. For example, multipletransaction types are executed dependent only on the various channelsused by the bank account/financial institution. This includes multiplepayment paradigms, such as 3-day settlement, next-day settlement, andinstant settlement. The CET service executes transaction using theprimary account 302 (financial instruments, including DDAs and creditcards (CCs)) as shown at 304, but the user financial information isnever shared with anyone, including the merchant or person being paid.The ET service enables the primary account 302 to be used forperson-to-person payments, direct-to-merchant payments (as shown at306), and any other type of transaction the user has available throughthe primary account 302. The funds from the primary account 302 aredeposited directly in the bank account 308 of the person or merchantbeing paid.

Aspects of the CET service 300 and advantages thereof as describedherein are particularly useful for a large financial institutiondesiring to incorporate the CET service in it offerings. Howeverembodiments are not so limited. Embodiments of the CET service may betailored as a stand-alone application or as an application tailored tobe presented as a service of a particular large or small entity.

Table 1 below lists some of the market opportunities in the area of bothonline payments and other areas, such as serving the unbanked.

TABLE 1 OPPORTUNITY FEATURES ONLINE Serving Online Businesses Transactusing primary PAYMENTS Provide easy-to-use and holistic DDA/Cardelectronic payment and merchant Online Direct-to- acquiring services toretail Merchant payments consumers and hobbyists with a OnlinePerson-to- special focus on online Person payments merchants Onlineinvoicing and collection (ACH/Card) Consolidated Reporting ServingOffline Businesses Online invoicing and Leveraging a large base ofcollection (ACH/Card) customers built in an adjacent Biller Direct forsmall business (Retail, Card, Merchant merchants Services, etc.) tobuild a network Consolidated of currently underserved offline Reportingmerchants and non profit Remote Deposit organizations Capture CallCenter Payments OTHER Add on Capability Serving the Direct-to-MerchantUnbanked Leveraging an and Person-to-Person emerging brand and ATM/payments via ATM/ Branch Networks to target the Banking Center Unbanked

Table 2 below describes lists some of the services offered to consumers(also referred to as users or customers herein) and to merchantsaccording to various embodiments.

TABLE 2 CONSUMERS MERCHANTS Transact using primary DDA/CARD Receivepayments from Card and Online Direct-to-Merchant payments DDA withoutmerchant acquiring Online Person-to-Person payment relationshipConsolidated Reporting across Online invoicing and collection multiplefinancial relationships (ACH/Card) (payments and requests for payment)For offline merchants, establish Privacy and security-Banking billerdirect website information is not shared with Manage accounts payablemerchants Consolidated Reporting across multiple financial relationships(payables and receivables) Other banking service-Remote Deposit Capturesweeps, etc.

FIG. 4 is a block diagram further illustrating direct-to-merchantpayment CET services and person-to-person payment CET services,according to an embodiment. In a direct-to-merchant scenario, a consumer(also referred to as a customer or user) 402 accesses a merchant website 404. As further described below, the merchant web site 404 ishosted by a financial management system that provides the CET service tomany users and merchants, thus making it possible for small merchants orindividual payees or billers to offer online payment. The CET service300 actually receives user input from the web site 404 and executestransaction accordingly. For example, the CET service 300 performsonline payment 406 as specified by the user 402 including DDA accountpayments at any financial institution, credit card payments, and shortterm loans.

In a person-to-person scenario, a user (also referred to as a customeror user) 408 accesses a DDA, for example through the web site of thefinancial institution 409 at which the DDA resides. The CET service 300actually receives user input from the financial institution 409 andexecutes transactions accordingly. For example, the CET service 300performs online payment as specified by the user 408 to one or more DDAsat another (payee) financial institution 410.

FIG. 5 is a block diagram illustrating biller-direct invoicing foroffline merchants, according to an embodiment. A small business 502communicates via a network (such as the Internet, a wide area network(WAN), etc.) with the CET service 300. The CET service 300 generatesinvoices or statements according to previously specified preferences ofthe small business 502. A customer 508 receives the invoice via mail, inthis case (the invoice could also be sent via email or another method).The customer 508 logs into either a central CET service web sitepresented by the financial management system that hosts the CET service,or a branded biller-direct web site. On either web site the customer 508can set up payments, view paid and unpaid invoices, view paymenthistory, and view outstanding balances. The customer 508 can scheduleelectronic payment of any invoices. The CET service executestransactions necessary to pay the invoice including depositing fundsfrom an existing customer account directly into an account designated bythe small business 502.

The online capability to pay invoices received offline providesconvenience to the customer, reduces payables processing cost for thecustomer, and makes payment time shorter. For small businesses, thiscapability reduces the time-to-pay and days outstanding. The capabilityalso allows small businesses to automatically reconcile receivables, andreduce receivables processing costs. For financial institutions, thiscapability can be offered as a value-added service to small businesses.Financial institutions can realize subscription and transaction feerevenue for providing the service.

FIG. 6 is a block diagram illustrating an embodiment in which the CETservice and network is used by the “unbanked” to conduct transactions,according to an embodiment. The unbanked include individuals that haveno way of making electronic payments. The unbanked must currently go tothe U.S Post Office or Western Union and obtain a money order ormoneygram in order to make payments. This is an opportunity forfinancial institutions to use their ATM/branch networks to allow theseunbanked consumers to transact offline for goods and services providedonline. In an example, a consumer 602 shops online at a merchant 604 andchooses to pay using a payment kiosk 606 which is via the CET service300 or the bank itself (such as bank 608). The consumer 602 receives aunique confirmation number and instructions to pay. The merchant 604receives the order and has the unique confirmation number. The consumer602 goes to a payment kiosk at a banking center. The consumer 602 usesthe confirmation number. Once the confirmation number is received itlinks the payment to the order. The consumer 602 can then select todeposit the funds directly. Some ATMs have the capability to scan cashin. The consumer 602 can also choose to walk up to a teller at the bank608 and make the payment. The bank 608 receives the payment on behalf ofthe merchant 604. This service enables the unbanked population to makequicker payments. This also facilitates much faster delivery of theproduct to the consumer 602. There can be a transaction fee associatedwith the service.

The CET service 300 can thus be very valuable to the unbanked consumerwho is enabled to make online purchases using cash or prepaid cards.Merchants also benefit because they can receive electronic payments fromeither banked or unbanked customers, expanding the customer base of themerchant. Financial institutions benefit by collecting transaction feerevenue. In addition, financial institutions have the ability tocross-sell other products or services to unbanked customers.

FIG. 7 is a block diagram of a system 700 including a financialmanagement system 702, according to an embodiment. The system 700includes various entities in communication with each other via a network710, which is typically the Internet, but embodiments are not solimited. The financial management system 702 includes databases 706 thatstore financial institution information, user information, merchantinformation (including merchant preferences for individual biller-directweb sites, invoice information for merchants, etc.). The CET service 300is included in the financial management system 702 and interoperateswith a funds transfer module 704. The funds transfer module 704communicates with multiple financial institutions to transfer funds asfurther described below. Servers 708 host multiple web sites andapplications as described herein, including biller-direct web sites, atleast one central CET service web site, invoicing applications, emailapplications, and setup applications, to name a few.

Merchants 712 communicate with the financial management system 702 asfurther described below for providing the CET service 300 to theircustomers, either through biller-direct web sites or through a centralCET services web site. CET customer personal computers (PCs) 716 are anexample of an interface between customers and the CET service 300.Customers may interface with the CET service 300 using other means, suchas handheld devices, kiosks, etc. Funds sources 714 include financialinstitutions of all types that can transfer funds via the network 710using established financial networks such as ATM, ACH, and debitnetworks.

FIG. 8 is a block diagram illustrating the operation of the fundstransfer module 704, according to an embodiment. Financial institution#2 is for the benefit of the funds transfer module 704, and in anembodiment is managed by a third party processor. In this instance“third party” infers that financial institution #2 is separate andindependent from financial institution #1 and financial institution #3.In order to transfer funds from a source account 802 (for example acustomer account) to a destination account 806 (such as a merchantaccount), the funds transfer module 704 first executes a debittransaction with the source account 802. Then the funds from the firstdebit transaction are deposited in the central (or intermediate) account804 in a first credit transaction.

The funds are then withdrawn from the central account 804 in a seconddebit transaction, and deposited in destination account 806 in a secondcredit transaction. Financial institutions #1 and #2 have no knowledgeof central account 804. This is in contrast to conventional electronicfunds transfers in which the financial institution providing the fundsand the financial institution receiving the funds must deal directlywith each other and have particular information or data about each otherin order to complete the transaction. As shown, the debit and credittransactions can be accomplished using any one of various existingnetworks, including but not limited to an ACH network, a debit network,and an ATM network.

FIG. 9 is a flow chart illustrating a CET service process 900, accordingto an embodiment. The financial management system (FMS) creates a hostedmerchant biller-direct (MBD) web site at 902. At 904, the merchantcustomizes the MBD web site, including look and feel with brandingindicia, specifying preferences such as merchant account(s), etc. Aregistered CET customer receives a merchant invoice with MBD web siteinformation (usually a link to the MBD web site) as shown at 906. Theregistered CET customer goes to the MBD web site to view the merchantinvoice at 908. At 910, the customer pays directly on MBD web site froma customer account (chosen previously per customer preferences). Paymentis transferred directly from the customer account to the merchantaccount at 912.

FIG. 10 is a flow chart illustrating a CET service process 1000 ofregistering a user, according to an embodiment. A customer logs into theCET service at 1002. The customer designates one or more existingaccounts from which to fund transactions at 1004. At 1006, the customerstates various verification information, such as user names, passwords,personal identification information, etc. The customer statespreferences at 1008, such as how the customer would like to receiveinvoices. All of the customer input is stored on the financialmanagement system and not shared with other entities, includingfinancial institutions, as shown at 1010. The registered customer canthen access and use the CET service by clicking on a CET icon to pay anymerchant that also uses the CET service at 1014. In addition, oralternatively, the registered user can then click on a branded orco-branded icon from a merchant site to pay the specific merchant at1012.

FIG. 11 is a block diagram of a system 1100 including a financialmanagement system 1102, according to an embodiment. The financialmanagement system hosts a central payment hub 1101 that includes a CETservice. The central payment hub 1101 is an industrial utility in thatmultiple financial institutions 1114 all participate in a centralservice that can be offered to their respective customers of thefinancial institutions. All of the customers (both individuals and smallbusinesses) of the various financial institutions access oneconsolidated payment hub 1101. For example a Bank of America invoice cancome into the payment hub 1101, and a Wells Fargo invoice can come intothe payment hub 1101. The payment hub 1101 is a shared utility acrossmultiple financial institutions 1114. The payment hub 1101 features asingle registration at the payment hub across all of the participatingfinancial institutions 1114. In an embodiment, the payment hub appearsto users (individuals and small businesses) as a single, neutrallybranded payment center across all of the participating financialinstitutions 1114. Therefore, there is a single registration required inorder for users to participate through any participating financialinstitution's web site or participating small business's web site.

In an embodiment, all of the participating financial institutions 1114offer the same neutrally branded or co-branded services to theircustomers and the services are provided by the central payment hub 1101.The value-added services this the payment hub allows the financialinstitutions 1114 to offer include originate point-to-point (P2P)payments, sending an invoicing and sending requests for payment ofinvoices, and merchant services/shopping cart payments on merchant websites.

The payment hub 1101 features a common payment center/directory thatenables customers to make payments on requests for payments/invoices,receive P2P payments, and make shopping cart payments on web sites forparticipating merchants' websites.

Participating banks 1114 can thus provide services to end users throughthe payment hub 1101, yet control the customer relationship.Participating banks 1114 underwrite and authorize service limits, andcollects revenues from subscriptions to the services.

Services to individual customers (or consumers) include sendingperson-to-person email payments, and sending requests for payment.

Services to small businesses include sending employee and vendorpayments to know third parties (where financial information sharedbetween sender and receiver), sending email payments to anyone (wherefinancial information is not shared between sender and receiver),sending invoices to collect payments, and sending shopping cart invoicesto collect point-of-sale (POS) payments.

The receiver role in transactions is supported by the financialmanagement system 1102 through the payment hub 1101. The receiverservices include receiving invoices or requests for payments, and makingpayments on both. The receiver services further include receiving(collecting) email payments, adding and verifying financial accounts(e.g., DDA, credit card), and assigning account preferences forreceiving payments or making payments on invoices or requests forpayments. In various embodiments, the roles of receiver and sender areless clearly separated. The roles could be combined in that many typicalreceiver or sender functions are performed by the opposite party. Thereceiver role could be extended to subsume the sender role in someinstances, for example.

The system 1100 includes various entities in communication with eachother via a network 1110, which is typically the Internet, butembodiments are not so limited. The financial management system 1102includes databases 1106 that store financial institution information,user information, and customer information (including invoiceinformation, payment information, payment history information,verification information, etc.). The CET service/payment hub 1101 isincluded in the financial management system 1102 and interoperates witha funds transfer module 1104. The funds transfer module 1104communicates with multiple financial institutions to transfer funds asfurther described below. Servers 1108 host multiple web sites andapplications as described herein, including biller-direct web sites,financial institution web sites, at least one central payment hubservice web site, invoicing applications, email applications, and setupapplications, to name a few.

Merchants 1112 communicate with the financial institutions 1114 toinitiate their participation in the payment hub 1101. Individualcustomers also communicate with the financial institutions 1114 toinitiate their participation in the payment hub 1101. Customer personalcomputers (PCs) 1116 are an example of an interface between customersand the financial institutions 1114 and between the customers and thepayment hub 1101 through the network 1110. Customers may interface withthe network 1110 using other means, such as handheld devices, kiosks,etc.

Aspects of the systems and methods described herein may be implementedas functionality programmed into any of a variety of circuitry,including programmable logic devices (PLDs), such as field programmablegate arrays (FPGAs), programmable array logic (PAL) devices,electrically programmable logic and memory devices and standardcell-based devices, as well as application specific integrated circuits(ASICs). Some other possibilities for implementing aspects of the systeminclude: microcontrollers with memory (such as electronically erasableprogrammable read only memory (EEPROM)), embedded microprocessors,firmware, software, etc. Furthermore, aspects of the system may beembodied in microprocessors having software-based circuit emulation,discrete logic (sequential and combinatorial), custom devices, fuzzy(neural) logic, quantum devices, and hybrids of any of the above devicetypes. Of course the underlying device technologies may be provided in avariety of component types, e.g., metal-oxide semiconductor field-effecttransistor (MOSFET) technologies like complementary metal-oxidesemiconductor (CMOS), bipolar technologies like emitter-coupled logic(ECL), polymer technologies (e.g., silicon-conjugated polymer andmetal-conjugated polymer-metal structures), mixed analog and digital,etc.

It should be noted that the various functions or processes disclosedherein may be described as data and/or instructions embodied in variouscomputer-readable media, in terms of their behavioral, registertransfer, logic component, transistor, layout geometries, and/or othercharacteristics. Computer-readable media in which such formatted dataand/or instructions may be embodied include, but are not limited to,non-volatile storage media in various forms (e.g., optical, magnetic orsemiconductor storage media) and carrier waves that may be used totransfer such formatted data and/or instructions through wireless,optical, or wired signaling media or any combination thereof. Examplesof transfers of such formatted data and/or instructions by carrier wavesinclude, but are not limited to, transfers (uploads, downloads, e-mail,etc.) over the Internet and/or other computer networks via one or moredata transfer protocols (e.g., HTTP, FTP, SMTP, etc.). When receivedwithin a computer system via one or more computer-readable media, suchdata and/or instruction-based expressions of components and/or processesunder the system described may be processed by a processing entity(e.g., one or more processors) within the computer system in conjunctionwith execution of one or more other computer programs.

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise,” “comprising,” and thelike are to be construed in an inclusive sense as opposed to anexclusive or exhaustive sense; that is to say, in a sense of “including,but not limited to.” Words using the singular or plural number alsoinclude the plural or singular number respectively. Additionally, thewords “herein,” “hereunder,” “above,” “below,” and words of similarimport refer to this application as a whole and not to any particularportions of this application. When the word “or” is used in reference toa list of two or more items, that word covers all of the followinginterpretations of the word: any of the items in the list, all of theitems in the list and any combination of the items in the list.

The above description of illustrated embodiments of the systems andmethods is not intended to be exhaustive or to limit the systems andmethods to the precise forms disclosed. While specific embodiments of,and examples for, the systems components and methods are describedherein for illustrative purposes, various equivalent modifications arepossible within the scope of the systems, components and methods, asthose skilled in the relevant art will recognize. The teachings of thesystems and methods provided herein can be applied to other processingsystems and methods, not only for the systems and methods describedabove.

The elements and acts of the various embodiments described above can becombined to provide further embodiments. These and other changes can bemade to the systems and methods in light of the above detaileddescription.

In general, in the following claims, the terms used should not beconstrued to limit the systems and methods to the specific embodimentsdisclosed in the specification and the claims, but should be construedto include all processing systems that operate under the claims.Accordingly, the systems and methods are not limited by the disclosure,but instead the scope of the systems and methods is to be determinedentirely by the claims.

While certain aspects of the systems and methods are presented below incertain claim forms, the inventors contemplate the various aspects ofthe systems and methods in any number of claim forms. For example, whileonly one aspect of the systems and methods may be recited as embodied inmachine-readable medium, other aspects may likewise be embodied inmachine-readable medium. Accordingly, the inventors reserve the right toadd additional claims after filing the application to pursue suchadditional claim forms for other aspects of the systems and methods.

1. A central electronic transaction method, comprising: a financialmanagement system hosting a central payment hub comprising a centralelectronic transaction (CET) service on behalf of a plurality offinancial institutions, wherein the payment hub manages information ofcustomers of the financial institution comprising individual customersand business customers, the information comprising requests for paymentand payment options; the financial management system receiving inputfrom a customer, the input comprising, customer information comprisingan identification of at least one payment account, wherein the at leastone payment account comprises an existing customer bank account; arequest to view customer invoices; and and a request to pay a customerinvoice; and the financial management system executing a transaction inresponse to the received input, comprising transferring funds from theat least one payment account to a destination account.
 2. The method ofclaim 1, wherein the requests for payment comprise invoices, statements,and electronic shopping carts.
 3. The method of claim 1, furthercomprising the payment hub implementing online invoicing for a businesscustomer through a web site identified with the business customer. 4.The method of claim 1, further comprising: a business customercustomizing a business customer web site to include a link to thepayment hub for the use of customers of the business; the businesscustomer designating one or more accounts to receive funds transferredby the payment hub on behalf of customers of the business; and thebusiness customer viewing consolidated payment and invoicing informationin response to a request to the payment hub.
 5. The method of claim 1,wherein the customer information comprises verification information forthe at least one payment account, including personal customeridentification information and password information.
 6. The method ofclaim 1, further comprising a customer of a business customer accessingthe payment hub via a link in an email from the business customer. 7.The method of claim 1, further comprising the customer accessing the website via a link on a web site of the payment hub.
 8. The method of claim1, further comprising receiving a customer registration that enables thecustomer to participate in the payment hub, comprising paying multiplepayees via the payment hub, wherein paying multiple payees comprisesviewing payee requests for payment on specific payee web cites andviewing multiple requests for payment from different payees on a paymenthub web site, wherein payees comprise the business customers.
 9. Themethod of claim 1, wherein executing the transaction comprises thepayment hub: executing a first debit transaction to withdraw funds fromthe at least one payment account at a first financial institution;executing a first credit transaction to deposit the funds in anintermediate account at a second financial institution; executing asecond debit transaction to withdraw funds from the intermediateaccount; and executing a second credit transaction to deposit the fundsin the destination account at a third financial institution.
 10. Themethod of claim 9, wherein the first debit transaction and the firstcredit transaction are executed using a first network.
 11. The method ofclaim 9, wherein the second debit transaction and the second credittransaction are executed using a second network.
 12. The method of claim10, wherein the first network is chosen from a group comprising: anautomatic clearing house (ACH) network; a debit network; an automatedteller machine (ATM) network, and a proprietary network.
 13. The methodof claim 11, wherein the second network is chosen from a groupcomprising: an automatic clearing house (ACH) network; a debit network;and an automated teller machine (ATM) network.
 14. A financialmanagement system comprising: a plurality of servers configurable tocommunicate with a plurality of financial institutions via at least onenetwork; and a plurality of storage devices, comprising, databases thatstore customer information, wherein customers comprise customers offinancial institutions including individual customers and businesscustomers, and financial institution information; and memory devicesthat store instructions that when executed, cause a central electronictransaction method to be executed, the method comprising, a centralpayment hub hosted by the financial management system on behalf of theplurality of financial institutions managing information of thecustomers of the financial institution, the information comprisinginvoices, payment options, and payment histories; the payment hubreceiving input from a customer, the input comprising, customerinformation comprising an identification of at least one source account,wherein the at least one source account comprises an existing customerbank account; a request to view customer invoices on the web site; and arequest to pay a customer invoice; and the payment hub executing atransaction in response to the received input, comprising transferringfunds from the at least one source account to a predetermineddestination account.
 15. The financial management system of claim 14,wherein the financial management system hosts multiple web sites onbehalf of multiple financial institutions.
 16. The financial managementsystem of claim 14, wherein the central electronic transaction methodfurther comprises: a business customer customizing a business customerweb site to include a link to the payment hub for the use of customersof the business; the business customer designating one or moredestination accounts to receive funds transferred by the payment hub onbehalf of customers of the business; and the business customer viewingconsolidated payment and invoicing information in response to a requestto the payment hub.
 17. The financial management system of claim 14,wherein the customer information comprises verification information forthe at least one source account, including personal customeridentification information and password information.
 18. The financialmanagement system of claim 14, wherein the central electronictransaction method further comprises an individual customer accessingthe payment hub via a link in an email from the business customer. 19.The financial management system of claim 14, wherein the centralelectronic transaction method further comprises an individual customerof a business customer accessing the payment hub via a web site of oneof the plurality of financial institutions.
 20. The financial managementsystem of claim 14, wherein the central electronic transaction methodfurther comprises performing a customer registration that enables thecustomer to participate in the payment hub, comprising paying multiplepayees via the payment hub, wherein paying multiple payees comprisesviewing payee invoices on specific payee web cites and viewing multipleinvoices from different payees on a payment hub web site, wherein apayee comprises an individual customer and a business customer.
 21. Thefinancial management system of claim 14, wherein executing thetransaction comprises the financial management system: executing a firstdebit transaction to withdraw funds from the at least one source accountat a first financial institution; executing a first credit transactionto deposit the funds in an intermediate account at a second financialinstitution; executing a second debit transaction to withdraw funds fromthe intermediate account; and executing a second credit transaction todeposit the funds in the predetermined destination account at a thirdfinancial institution.
 22. The financial management system of claim 21,wherein the first debit transaction and the first credit transaction areexecuted using a first network.
 23. The financial management system ofclaim 22 wherein the second debit transaction and the second credittransaction are executed using a second network.
 24. The financialmanagement system of claim 22, wherein the first network is chosen froma group comprising: an automatic clearing house (ACH) network; a debitnetwork; and an automated teller machine (ATM) network.
 25. Thefinancial management system of claim 23, wherein the second network ischosen from a group comprising: an automatic clearing house (ACH)network; a debit network; and an automated teller machine (ATM) network.26. A method for central electronic transaction management, the methodcomprising: hosting a central payment hub for a plurality of financialinstitutions; supporting web site links on web sites of the plurality offinancial institutions which link to the central payment hub, whereineach of the financial institutions offers a plurality of central paymenthub services to its customers, the services comprising invoicing andpayment services; receiving customer preferences comprising at least onedesignated destination account in which funds are to be deposited by thepayment hub on behalf of a customer; receiving registration input from acustomer comprising customer personal information and customer sourceaccount information regarding an account from which funds are to bewithdrawn to make payments on behalf of the customer; receiving inputfrom the customer comprising, a request from the customer to viewinvoices; a request to pay an invoice; a request to view paymenthistory; and a request to send an invoice on behalf of the customer; andexecuting a transaction in response to the request to pay comprisingtransferring funds from the customer source account to the at least onedesignated destination account.
 27. The method of claim 26, wherein thecustomer comprises an individual customer of a financial institution anda business customer of the financial institution.
 28. The method ofclaim 27, further comprising an individual customer of one of theplurality of financial institutions viewing invoices, paying invoices,and viewing payment history, wherein the invoices and the paymenthistory are related to any business customer of any of the plurality offinancial institutions by accessing the payment hub.